Setting Up Windows Server and Active Directory

Overview

This project covers the setup of a Windows Server 2022 Domain Controller and a basic Active Directory environment. The goal was to build a functioning domain on Proxmox consisting of a Domain Controller and two Windows 11 Pro workstations joined to the domain, simulating a corporate network environment within the network lab subnet.

Environment:

• Proxmox
• Network Lab LAN
• NetLab.private

VMs Created:

• DC01 — Domain Controller and DNS Server — 10.10.10.10 (static IPv4)
• WS01 — Windows 11 Pro Workstation — DHCP assigned (10.10.10.x)
• WS02 — Windows 11 Pro Workstation — DHCP assigned (10.10.10.x)

To Start

Upload your Windows Server 2022, Windows 11, and VirtIO driver ISO files to Proxmox and create three separate VMs. The first will serve as the Domain Controller and runs Windows Server 2022. Windows Server 2022 was chosen over 2019 for its improved security features and longer support lifecycle. The Windows 11 VMs must be version Pro or higher. Windows 11 Home does not support Active Directory domain join. Ensure the VirtIO ISO is mounted as a secondary CD/DVD drive on each VM so driver files are accessible during installation.

Windows Server 2022 Setup

With the installation complete, right click the Windows logo and select Device Manager. Under "Other Devices", locate any entries marked with a yellow warning triangle. These represent hardware devices without drivers installed and will typically appear as "Unknown Device". Manually update each one by pointing the driver search to the appropriate folders on the VirtIO ISO: vioscsi for the storage controller, NetKVM for the network adapter, and vioserial for the serial port. The VirtIO guest agent installer on the ISO will handle any remaining devices automatically.

With drivers updated, the next step is to assign a static IP to the Domain Controller. Open the network adapter settings and configure the following: IP address 10.10.10.10, subnet mask 255.255.255.0, default gateway 10.10.10.1 (OPNsense LAN interface), and DNS server 127.0.0.1 (loopback, since the DC will serve as its own DNS once Active Directory is installed). The server was also renamed to DC01, which requires a restart. Once restarted, open Server Manager and select Add Roles and Features. Configure the role installation as follows:

• Role-based or feature-based installation
• DC01 selected as the destination server
• Active Directory Domain Services selected as the server role
• Proceed through remaining screens and click Install

Once installation completes, promote the server to a Domain Controller using the notification flag in Server Manager. Configure the promotion as follows:

• Add a new forest with the root domain name NetLab.private
• Windows Server 2016 for both forest functional and domain functional levels
• Domain Name System (DNS) Server enabled
• Global Catalog enabled
• DSRM password configured — this is used for directory services restore mode recovery and should be saved securely
• Proceed through remaining screens and allow the server to restart automatically

Windows 11 Workstation Setup

With the Domain Controller configured, the next step is setting up the workstations. Create two Windows 11 Pro VMs with the same hardware parameters used for the server. Keep disk size generous, as Windows 11 requires significantly more storage than previous versions. A local user account can be created during setup for initial access, as the login method will change once the workstations are joined to the domain.

Before joining the domain, the DNS configuration on each workstation must point to the Domain Controller rather than OPNsense. Navigate to the network adapter settings and set the preferred DNS to 10.10.10.10 (DC01) with an alternate DNS of 10.10.10.1 (OPNsense) as a fallback for external resolution. Since DHCP is handled by OPNsense and workstation IPs do not need to be static, only the DNS entries need to be configured manually.

With DNS configured, open System Properties by running control sysdm.cpl and navigate to the Computer Name tab. Click Change, select Domain, and enter NetLab.private. When prompted, enter the domain Administrator credentials. On a successful join, a welcome message will confirm the workstation has been added to the domain. Rename each workstation to WS01 and WS02 respectively, then restart.

Final Steps

With the Domain Controller configured and both workstations joined, the final step is to verify connectivity. On DC01, open Server Manager, navigate to the Tools menu in the top right, and select Active Directory Users and Computers. First, navigate to the Users container and create a test domain account. Then open the Computers container and confirm both WS01 and WS02 appear there, indicating a successful domain join.

Boot either workstation and verify the domain account works by clicking Other user on the login screen and entering the test account credentials in the format NETLAB\username. A successful login confirms the workstation is communicating with the Domain Controller for authentication. Active Directory is now operational.

Problems Encountered

This project is straightforward as long as the steps above are followed carefully. The first issue encountered was with Windows 11 Home edition. During initial setup, the Home edition was installed without considering its compatibility limitations with Active Directory. Windows 11 Home completely disables and hides the domain join option in System Properties, and no amount of PowerShell commands or workarounds resolved it. Both workstations had to be reinstalled using Windows 11 Pro.

The second issue involved DNS configuration. OPNsense was initially set as the DNS server on the workstations (10.10.10.1), which caused the domain join to fail because OPNsense has no knowledge of the NetLab.private domain. Pointing DNS to the Domain Controller (10.10.10.10) resolved the issue, as the DC hosts the authoritative DNS zone for the domain.

An interesting observation during troubleshooting was that Windows 11 Home generated no Event ID 4625 entries in the Security audit log during failed domain join attempts. Event ID 4625 is a Windows Security event that logs failed account authentication attempts, including wrong passwords and unauthorized access. It appears Windows 11 Home suppresses or disables this auditing entirely. PowerShell commands targeting domain join also terminated immediately without executing, further confirming that Home edition blocks this functionality at the OS level rather than just hiding it in the UI.

Closing Notes

This project reinforced how tightly Active Directory depends on DNS. Without the Domain Controller serving as the DNS authority for the domain, workstations have no way to locate or authenticate against it, regardless of network connectivity. A successful ping to the DC means nothing if DNS is misconfigured; the domain join will fail at the authentication stage every time.

The Windows 11 Home issue was a valuable lesson in understanding OS edition licensing and feature sets. In enterprise environments, workstation editions are managed through volume licensing and enforced by IT policy precisely because Home edition lacks the management and security features that corporate infrastructure requires.

Troubleshooting with Event ID 4625 also introduced the concept of Windows Security auditing, which becomes increasingly important in the next phases of this lab as Sysmon and a SIEM are introduced. Understanding what gets logged, what does not, and why is a foundational skill in both systems administration and security operations.

Back to Home